Dynamic interface between bpss conversation management and local business management

ABSTRACT

The present invention relates to devices and methods that coordinate an external conversation process between entities with an internal workflow of one of the entities. More particularly, it relates to devices and methods that are compliant with an inter-enterprise conversation process standard for routing electronic commerce documents between enterprises. Particular aspects of the present invention are described in the claims, specification and drawings.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.13/615,197, titled “DYNAMIC INTERFACE BETWEEN BPSS CONVERSATIONMANAGEMENT AND LOCAL BUSINESS MANAGEMENT” filed on 13 Sep. 2012, whichis a continuation of U.S. patent application Ser. No. 12/789,776, titled“DYNAMIC INTERFACE BETWEEN BPSS CONVERSATION MANAGEMENT AND LOCALBUSINESS MANAGEMENT” filed on 28 May 2010, which issued as U.S. Pat. No.8,301,573 on 30 Oct. 2012, which is a continuation of U.S. patentapplication Ser. No. 10/222,008, “DYNAMIC INTERFACE BETWEEN BPSSCONVERSATION MANAGEMENT AND LOCAL BUSINESS MANAGEMENT” filed on 15 Aug.2002, which issued as U.S. Pat. No. 7,729,922 on 1 Jun. 2010. Theoriginal '008 application is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

The present invention relates to devices and methods that coordinate anexternal conversation process between entities with an internal workflowof one of the entities. More particularly, it relates to devices andmethods that are compliant with an inter-enterprise conversation processstandard for routing electronic commerce documents between enterprises.

E-business is moving toward a paradigm in which enterprises interactwith each other through exchanging XML documents based on well-definedprotocols such as SOAP, WSDL, ebXML, which enables them to interoperatetheir Web services in a dynamic and loosely coupled way [T. Bray, J.Paoli, C. M. Sperberg-McQueen, “Extensible Markup Language (XML) 1.0Specification”, February 1998, (http://www.w3.org/TR/REC-xml),EbXML.org, Business Process Specification Schema”, V1.01, 2001, SOAP,“Simple Object Access Protocol”,http://msdn.Microsoft.com/xml/general/so-apspec.asp, www.w3c.org, WSDL,“Web Service Description Language”, www.w3c.org.]. In order forenterprises to collaborate at the business-process level, channels mustbe developed to allow the business processes that run on their localsites to interact. Several Inter-enterprise Conversation Process (ICP)specification standards have been proposed such as ebXML BPSS (BusinessProcess Specification Schema) [EbXML.org, Business Process SpecificationSchema”, V1.01, 2001], WSCI (Web Service Choreography Interface) [WSCI,“Web Service Choreography Interface”, Tech Report by Italio, SAP, BEA,Sun Microsystems. 2002], WSCL (Web Service Conversation Language) [WSCL,“Web Service Conversation Language”, HP Submission to W3C, www.w3c.org].As shown in FIG. 1, an ICP specifies the choreography of documentexchange as an abstract interface, leaving the processing andprovisioning of documents to local business processes or services. Inthis illustration, two parties are represented by two columns ofbusiness documents. Transmission of an order 101 lends to an invoice111. The invoice eventually prompts a payment 102, after whichmerchandise is shipped and a shipping notice 112 is generated. Asillustrated in the figure, the two parties have internal processes thatcommunicate through a conversation process. As an abstract interface,one ICP can be supported by a variety of business processes and serviceswith different implementations. However, none of the ICPs specify howlocal business processes couple their internal and external processes.

Accordingly, an opportunity arises to develop methods and devices thatcoordinate between an external ICP and an internal workflow.

SUMMARY OF THE INVENTION

The present invention relates to devices and methods that coordinate anexternal conversation process between entities with an internal workflowof one of the entities. More particularly, it relates to devices andmethods that are compliant with an inter-enterprise conversation processstandard for routing electronic commerce documents between enterprises.Particular aspects of the present invention are described in the claims,specification and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts interaction between two businesses each having its ownlocal business process system.

FIG. 2 depicts a conversation process manager including a conversationmanager and a workflow engine.

FIG. 3 illustrates the BPSS collaborator in a conversation managementsystem.

FIGS. 4 and 5A and 5B illustrate, with backfilling, processing ofinter-enterprise conversation process messages by an order processingsystem.

FIGS. 6 and 7 provide additional detail regarding interaction of a BP SSconversation manager and a process manager.

FIG. 8 illustrates one embodiment of tight coupling between conversationmanager and a process manager.

DETAILED DESCRIPTION

The following detailed description is made with reference to thefigures. Preferred embodiments are described to illustrate the presentinvention, not to limit its scope, which is defined by the claims. Thoseof ordinary skill in the art will recognize a variety of equivalentvariations on the description that follows.

An ICP (or simply a conversation process) is not executed on acentralized server, but carried out by multiple participating parties.Each party is responsible for enforcing its peer-view of theconversation process. This typically includes verifying the inbounddocuments and controlling the sending of outbound documents according tothe ICP specification.

At one business site, a conversation process that handles documentexchanges is coupled with a local business process handling a workflowof tasks for document processing and provisioning. In turn, these tasksare actually performed by the concrete actions, services and other localbusiness processes.

There is or should be independence between “conversation activities” and“process tasks”, and between tasks and actions. For an externalconversation process between entities, the conversation activitiestypically are interface level objects internal to the conversationprocess, and tasks for supporting the conversation activities typicallyare implementation level objects defined externally to the conversationprocess. For a business process, managed by an entity, the taskstypically are interface level objects internal to the business process,and actions for performing the tasks typically are implementation levelobjects defined externally to the business process. This implies that aso-called Collaborative Process Manager (CPM) for supportinginter-enterprise collaboration is potentially made of threecommunicating components, as illustrated in FIG. 2. The componentshandle conversations 211, local business processes 213 and actions 214,respectively. The so-called Conversation Manager (CM) 211 handlesinter-enterprise business interaction 201 based on an ICP model(conversation model). A core function of CM is to enforce thechoreography of document exchange. The so-called Process Manager (PM)213 runs local processes based on a business process model. A corefunction of PM is to enforce the rules for triggering tasks. These taskscontribute to the accomplishment of the local process, includingdocument manipulation as required by the conversation activities. TheAction Manager (AM) 214 dispatches and invokes local applications,services or processes to perform process tasks. An action provides anactual implementation of document processing, provisioning or otherapplications. Actions may be called through local or remote invocation,based on CORBA, WSDL, etc. The invocation may be made synchronous orasynchronous. The PM and AM can both be implemented as parts of aworkflow engine 212. On the internal side of interactions 221, the CPM210 may interact with users 222, private process engines 223 orapplication servers 224. The functions of conversation management,process management and action management may be combined in a CPM system210, or provided by separate but communicating systems.

In this document, CPM is a general name rather than any specific system.By conversation process, we mean the one describing conversation flow;by business process we mean the one describing workflow. For clarity, wedistinguish the basic operations of conversation processes and businessprocesses by calling them conversation activities and tasksrespectively.

In supporting business collaboration, CM focuses on enforcing theconstraints of inter-enterprise document flow; PM focuses on enforcingthe constraints of intra-enterprise task scheduling. CM deals withchoreographed document exchange; PM deals with document processing andprovisioning accordingly, as well as the issues on transaction,recovery, concurrency, etc, in the context of process management.

At a business site, a conversation process, say C, defining thechoreography of document exchange, actually indicates the expectedbehavior of the coupling business process, say, P, for processing andproducing the corresponding documents. If P can process and providedocuments in the order that matches the order of document receiving andsending specified in C, we say P can be used support C.

In general, the conversation process and the coupling business processare based on different models. A conversation activity has twooperations for delivering requesting and responding documents, which maymap to one or more local tasks for consuming and producing thedocuments. The ICP models for conversation process standards such asBPSS [EbXML.org, “Business Process Specification Schema”, V1.01, 2001],WSCI [WSCI, “Web Service Choreography Interface”, Tech Report by Italio,SAP, BEA, Sun Microsystems. 2002], etc., are all different from thetraditional workflow models such as WFMC's reference model [WorkflowManagement Coalition, www.aiim.org/wfmc/mainframe.htm]. The choreographyof conversation activities and the flow of task execution are alsosemantically different. Since in business interactions, a systemoperated by one party cannot control the behavior of systems operated byother parties, the choreography of interactions should be verified withrespect to a commonly agreed conversation model. In presentcircumstances, with a variety of emerging standards, a conversationprocess standard selected by parties to a conversation may besupplemented by an express conversation process agreement between theparties, either bilateral or as participants in a group.

In the following section we shall discuss two major issues: theconversation management and the dynamic interface between conversationmanagement and local business process management based on theconversation model-driven asynchronous task activation mechanism.

Conversation Manager for Supporting Inter-Enterprise Collaboration

We have developed a CM system that we call BPSS collaborator, forhandling choreographed conversation under the ebXML Business ProcessSpecification Schema (BPSS) standard [EbXML.org, Business ProcessSpecification Schema”, V1.01, 2001]. One of skill in the art willrecognize that the following description also applies or can be extendedto ICPs other than BPSS, such as WSCI or WSCL, or any emerging orlater-developed ICP standard.

BPSS

The ebXML BPSS is a standard XML-based language for specifyinginter-enterprise conversation processes. In BPSS, a conversation processis called collaboration. A binary collaboration has two authorized-rolesand a multi-party collaboration has more than two partner-roles. Thebusiness partners participating in a collaboration process play theseroles; they interact through a set of choreographed conversationactivities (called business activities in BPSS). A conversation activitymay represent a business transaction consisting of one or two predefinedbusiness document flows between the participating roles. Iteratively, aconversation activity may also represent a nested binary collaboration.In general, the BPSS model is a conversation process model; it providesthe abstract interfaces of business interaction, regardless of theconcrete implementation.

Different from the usual business process or workflow specifications, aBPSS only describes the public interface between business partners,which is essentially the document exchange between them. Different fromthe tasks in a business process, a conversation activity in aconversation process usually represents two operations: a request and aresponse between the two participating roles. Moreover, different fromthe flat business process models, the BPSS model is hierarchicallystructured.

BPSS Collaborator—A CM Based on BPSS Model

The BPSS collaborator in FIG. 3 is a CM system 311 that we developed forhandling BPSS based, peer-to-peer binary or multi-party collaboration.At a business site that participates in an inter-enterprisecollaboration, the primary function of the BPSS collaborator 333 is toenforce the “interaction-flow” constraints 332 with its partners 300,based on the BPSS conversation process model. A particular conversationis a collaboration instance 334. The concrete implementation of documentmanipulation is left to local workflow systems and services 321.

A collaboration specified in BPSS includes multiple choreographedconversation activities having a history, rather than a single round ofdocument exchange. Thus, the BPSS collaborator 333 handles conversationactivities in the way analogous to workflow system handling processtasks. Enforcing the choreography of conversation activities at abusiness site preferably takes into account not only the existence ofinbound and outbound documents, but also the order and time for thosedocuments to be sent or to be received (i.e., the history of thecollaboration instance). This function is not covered by conventionalworkflow systems. Further, since inter-enterprise collaboration is notcontrolled by a single enterprise, and the behavior of other enterprisesmay not be trusted by default. The choreography of document exchangespreferably is validated by the collaborator 333 taking into account boththe schema or interaction constraints 332 and the history of theparticular interaction 334.

Given the above requirements, the BPSS collaborator provides thefollowing functions. It supports the BPSS definition model, includingthe creation, maintenance and manipulation of conversation processtemplate objects in Java or another programming language. These objectsare created by parsing the XML specifications into DOM trees or othertree structures and then by turning the trees into the correspondingJava objects. It supports the BPSS instance model at runtime, includingcreating, maintaining and evolving local-site collaboration instancesstep by step along with the business interactions. It verifies thechoreography of conversation activities (conversation-flow) based on thetemplate model 332 and the execution history of each collaborationinstance 334. These are core functions for enforcing the documentexchanges constraints in multi-party or binary collaborations; forchecking the consistency of document exchange with respect to thecollaboration context, document types, participating roles, etc; forevolving conversation process instances consistently with respect to theinter-enterprise messages; and for ensuring peer-wise synchronization ofconversation process executions. The results of the BPSS model basedrun-time verification are used to determine the correctness of documentsending and receiving, and to generate the conditions for activatinglocal process tasks to process inbound documents and provide outbounddocuments. Regarding to the interface to PM, the information returnedfrom the BPSS collaboration verification operations is used to insertmessages, portions of messages or information about messages into a taskactivation data structure that is used to activate the local processtasks asynchronously. The system manages collaboration sessions,including initiating and maintaining the global conversation instanceand Id for each conversation process, and at a participant site,correlating the conversation Id with the local processes, tasks oractions that support the corresponding conversation process. The systemmanages collaboration roles. Under BPSS, this includes resolving,maintaining and retrieving the authorized-roles for binarycollaboration, and partner-roles for multi-party collaborations. Thisallows a party to play different roles in multiple binary collaborationsinvolved in a conversation process hierarchy or in a multi-partycollaboration. And, the system monitors collaboration instances. A webinterface may be provided for monitoring the collaboration status,documents exchanged, etc, with other partners.

The logical execution of a BPSS conversation process actually involvestwo or more peer-executions at the participant sites. At each site, apeer conversation process instance 314 is built and evolved step by stepas the document exchanges go on. The history of the conversation ismaintained as part of the instance. For business documents, either sentor received, the BPSS collaborator will search the conversation processtemplate to identify the conversation activity, transaction, requestingoperation or responding operation that match the delivered document; andlocate, update or create the corresponding instances if they areconsistent with the template. Unlike a business process instance that isevolved by the workflow engine, a conversation process instance isevolved as the reaction to document exchanges, so in most cases it isback-filled.

FIG. 4 shows a conversation process example with two level nesting. Itsinstance is created and evolved according to document exchange. Forverifying a document delivery, the collaborator takes conversation ID,document type, sender, receiver and activity name as input parameters,validates these information based on the conversation process templateand instance, returns verification results to the local service such asa coupling workflow engine, and evolve the conversation processinstance. In this example we can see three conversation processes atdifferent levels: “OrderManagement” 401, “Ordering” 411 and “Checking”421. “Order” 403 and “Check” 412 are collaboration activitiesrepresenting nested conversation processes; other activities specifydocument flow between two roles. Activities “Submit Change” 414 and“Check Status” 415 can be repeated. These conversation processes aredefined with different roles. Accordingly, a party will play differentroles in the conversation process instances at different levels, and therole resolution and switching are the functions provided by thecollaborator.

To show how a conversation process instance evolves in the waydifferently from how a business process instance evolves, we illustratein FIGS. 5A-B the conversation instances upon the first two documentsdelivered. The first Order Management 501 document should be therequesting document for conversation activity “Contact” 502; thisactivity specifies one-way document delivery. When the document deliveryis validated, the conversation process instance looks like FIG. 5A. Thesecond Ordering 511 document should be the requesting document 512 ofconversation activity “CheckAvailability” 523, and if validated, theconversation process instance is evolved to FIG. 5B. A response 522 isreturned. We can see clearly how the containing conversation processes“Ordering” 511 and “Checking” 521 are instantiated to hold thisconversation activity, in the “back filled” way.

Possible Architectures for Interacting CM and PM

While the BPSS collaborator handles conversation activities, documentconsumption and production are implemented as local business processesand services. As a CM system, the BPSS collaborator can interface toeither a PM or an AM; and there are several configurations for a CM andPM to interact.

First, a stand-alone ICP engine can be constructed around the CM tosupport only conversation activities. The CPM built on this architecturehas the following limitations. This architecture does not supportprocesses involving the local tasks other than conversation activities;therefore it does not readily accommodate the usual case that anenterprise business process is defined for conducting both publicinteraction and private applications. It does not allow a publicconversation process to interact with a running local process. Further,the local services invoked by the CPM as separate points of service(POSs), are not correlated at the business process level. Thisarchitecture has to deal with the scalability on its own as it cannotrely on a local workflow engine to do so. Therefore, it must befacilitated with a full spectrum of process management functions, withconsiderable overlap to an enterprise workflow engine.

Second, a workflow engine can have the CM as its front-end for handlingbusiness conversation. The major limitation of this architecture is thatthe BPSS collaborator has its own inter-enterprise messaging logic, andtherefore must ensure the throughput, security, etc, of messagedelivery. In case the backend workflow engine includes this logic, theBPSS collaborator should be able to reuse it, which leads to thearchitecture described below.

Third, an extended workflow engine can have the CM plugged in. This lastarchitecture increases usability of existing workflow system components,supports both conversation processes and local processes, and simplifiesthe interface between CM and PM. By providing CMs under different ICPstandards, a CPM can support multiple ICP languages.

CM as Model-Driven Asynchronous Task Activator

Synchronous and Asynchronous Task Activation

In conventional workflow models, conceptually a task is triggered by thesatisfaction of so-called “task activation conditions”. When a processis specified with inter-linked tasks, a link from task Tp to task Tactually represents an activation condition of T relating to theexecution status of Tp. From this point of view, a business process mayalso be viewed as a set of rules for task activation, processtermination, etc.

We distinguish two general mechanisms of task activation: synchronousactivation and asynchronous activation. Given a task T, synchronousactivation means an event, such as notifying the status of a precedenttask, directly activates T. Asynchronous activation means an eventcauses the update of a task activation data structure underlying thetask activation condition of T, which may potentially make the taskready to run. Checking conditions and activating T is handled by aseparate, asynchronous thread of control. Activating a task may meanexecuting it right away or schedule it to run.

Conversation Model Driven Asynchronous Task Activation

Given a conversation process, C, and the coupling local businessprocess, P, even if the task flow of P is consistent with the order ofdocument exchange specified in C, it is difficult to synchronize theexecution paces of P and C, especially when P involves other privateapplications and runs at a different pace from C.

Asynchronous task activation is the mechanism for solving the difficultyof synchronizing a conversation process instance and the correspondinglocal business process instance. Referring to FIG. 6, asynchronous taskactivation may include the following. A task 661 can be scheduled to runbased on certain task-activation conditions 651, and these conditionsare checked against certain underlying data. The evolving 635 of aconversation process instance 634 upon document exchange 647 generatesthe information for updating 651 the task activation data structureunderlying task activation-conditions. Asynchronously, the taskscheduler 652 of a PM 613 will check those conditions 651 to scheduletasks 661, as a separate thread of control. The task activation datastructure updates can be made by the CM using PM's API, or by the PMusing CM's API.

Regarding to BPSS-based conversation, validation of documents sent andreceived, may involve the following attributes: collaboration ID;conversation-activity name that represents a service; sender; receiver;and document name.

Based on the template 632 and execution instance of the BPSSconversation process 634, when the above document exchange informationis validated, information 646 may be returned; otherwise appropriateerror messages may be returned. The returned information 646 includes:collaboration ID; conversation-activity; interaction-time; requestingplayer and its role; responding player and its role; document name;action-type (“responding” or “requesting”); validation status.

These resulting data may be selected to underlie task-activationconditions. A mapping between the information generated by CM and a taskactivation data structure is provided. Different mappings may adapt theCM to different workflow engines. With such mappings, conversationprocesses and local business processes can be defined independently.FIG. 7 is a more detailed illustration of the conversation model drivenasynchronous task activation. Some numbering of this figure parallelsthe numbering in FIG. 6. In a public process 701, a document exchangemessage 747 is sent from one entity to another. This document exchangemessage 747 may include a collaboration ID, an activity, andidentifications of the sender and receiver. The document exchangemessage is received for processing by a collaborator 733. Thecollaborator 733 has access to a BPSS template 732 that specifies rulesor constraints on inter-enterprise conversation processing, preferablyin the form of a schema. The collaborator 733 also has access to a BPSSinstance 734 that includes a history of a particular conversation,typically tracked by collaboration ID number. The collaborator 733verifies the message received, preferably against both the template 732and a conversation history 734. The validated results 746 may include acollaboration ID, an activity, an interaction timestamp, a request-roleparty identification, a response-role party identification and adocument name corresponding to the message. The message, a portion ofthe message or information responsive to the message is entered into atask activation data structure 753. The task activation data structuremay include a collaboration ID, sender-role, receiver-role, servicerequested and document name. It may include various additionalinformation used to activate tasks in an internal workflow. Anadditional data structure 751 includes task activation conditions. Aworkflow manager compares data in the task activation data structure totask activation conditions to determine when tasks, such as orderprocessing 762 in a private process 722 should be activated, deactivatedor otherwise processed.

With the above architecture, the functions of CM and PM have separatefunctions. As shown in FIG. 8, the CM 811 is responsible for managingconversations under a conversation process model 801, the PM 813 isresponsible for managing the coupling of local processes 822 based onits workflow model. However, treating the BPSS collaborator as the CMbuilt into the CPM 810 rather than as a front-end CM can free it fromhandling inter-enterprise messaging directly, allowing it to rely on thecapability and scalability of the workflow engine logic 818 to do so. Asshown in FIG. 8, in this case the CM does not act as a“message-interceptor”. Tightly coupling a CM and a PM under theasynchronous task activation mechanism represents an elegant approach tobridging a conversation model 801 and a business process model 822. Whenthe BPSS collaborator verifies document exchanges and uses theverification results to set up data for the task activation conditionsfor the local processes, the BPSS collaborator may be viewed as theextension of the PM's rule engine for task scheduling. And theconversation process instance may be viewed as the extension of the taskactivation data structure that is searched by the rule engine throughAPIs.

From this point of view, the BPSS collaborator can be characterized as aconversation model driven asynchronous task activator with which therule based task scheduler interacts. This architecture modifies the CMfunction from an “active component” to a “passive component”controllable by the PM through APIs. This architecture supports thefollowing features. It has a public interface. The BPSS collaboratorprovides BPSS model based conversation management. However, it does notintercept inter-enterprise messages; instead, it obtains the informationon inter-enterprise interaction from the CPM platform. It has a localinterface. The BPSS collaborator interfaces to the local PM throughAPIs, and can be characterized as a conversation model drivenasynchronous task activator. It interacts with private processes. Aconversation process instance can interact with a running local processunder the asynchronous task activation mechanism; the local businessprocess can have mixed tasks for handling interchanged documents and forother private actions.

A preferred architecture that uses a conversation manager as a plug-into a workflow manager provides a clear separation of inter-enterpriseconversation management and local business process management. It allowsthe maximal usability of existing workflow system components, supportsboth conversation processes and local processes and allows aconversation process to interact with a running local process. Based onthe notion of conversation model driven asynchronous task activation,this architecture bridges the conversation model and the businessprocess model, and supports seamless integration of CM and PM. MultipleCM-based conversation model driven asynchronous task activators underdifferent ICP standards can be provided which allow the CPM to supportmultiple ICP languages.

As ICP standardization is ongoing, it is understood that multipleconversation managers or components of a single CM, based on several ICPmodels, such as BPSS, WSFL and WSCI, can support multipleinter-enterprise interaction standards.

In order for enterprises to collaborate at the business-process level,they must allow the business processes run on their local sites tointeract. Each party participating in an inter-enterprise collaborationneeds to deal with two kinds of processes: the public conversationprocess specifying the “conversation-flow”, and the local businessprocess specifying the “workflow” that fulfills the conversationactivities. How to integrate conversation-flow management and workflowmanagement, particularly, how to make full use of an existing workflowengine to support inter-enterprise collaboration, is a challenge.

Several architectures for interoperating a conversation manager and aprocess manager based on conversation model driven asynchronous taskactivation have been described that support extended use of existingworkflow system components, support both conversation processes andlocal processes, and provide a dynamic and simple interface betweenconversation management and process management.

This work, addressing peer-to-peer process interaction, clearly differsfrom the centralized workflow management [Workflow Management Coalition,www.aiim.org/wfmc/mainframe.htm], from the conventional processinter-operation for enforcing ad-hoc task dependencies and dataexchanges in a single enterprise, and from the process invocation basedprocess decentralization seen in [M. Koetsier, P. Grefen, J. Vonk,“Contracts for Cross-Organizational Workflow Management”, Proc.EC-Web'2000], etc. This work has also elevated the peer-to-peerinteraction to the process level [Qiming Chen, Meichun Hsu, Umesh Dayal,Martin Griss, “Incorporating Multi-Agent Cooperation, Dynamic Workflowand XML for E-Commerce Automation”, Proc. Fourth InternationalConference on Autonomous Agents, 2000, Span, Qiming Chen, Umesh Dayal,Meichun Hsu, Martin Griss, “Dynamic Agent, Workflow and XML forE-Commerce Automation”, Proc. First International Conference onE-Commerce and Web-Technology, 2000, UK, Chweh C R, “Peer-to-peercomputing transforms file-sharing and large-scale distributed computing,IEEE Software, Vol. 18, No. 1, 2001, and Clark D, “Face-to-face withpeer-to-peer networking”, Computer, Vol. 34, No. 1, 2001].

Different from WSDL [WSDL, “Web Service Description Language”,www.w3c.org], WSFL [WSFL, “Web Service Flow Language”,www-3.ibm.com/software/solutions/webservices/], Rosetta-net [WSCI, “WebService Choreography Interface”, Tech Report by Italio, SAP, BEA, SunMicrosystems. 2002], and BPML [BPML, “Business Process Markup Language”,www.BPMI.org. 2002], that support point of conversation not directlycorrelated at the process-level, this work focuses on choreographedconversation. The standards body approach of dealing with points ofconversation can provide certain flexibility, but can hardly follow acommonly agreed conversation model standard such as ebXML BPSS.Furthermore, WSFL, BPML and WSCL, etc, are used to offer a single partyview rather than the public view, to the collaboration. As a result, animplementation does not present a general model of peer-to-peersynchronized execution; for instance, it does not intend to specify howthe partner process instances are synchronized or are made aware of theprogress of the peer processes.

It should be recognized that aspects of this invention integrateinter-enterprise collaborations with intra-enterprise businessprocesses. This is a practical challenge faced by many organizations.Fundamental differences exist between conversation models that underliethe ICP standards and the conventional business process models that theexisting workflow engines support. Most of the current efforts arecharacterized by adopting a model that either “simulates” conversationactivities by the business process tasks, or takes local processes as“point of services” to “fulfill” conversation activities [BEA System,InTalio, SAP, Sun Microsystems, “Web Service Choreography Interface”,2002, BPML, “Business Process Markup Language”, www.BPMI.org. 2002,WSFL, “web Service Flow Language”,www-3.ibm.com/software/solutions/webservices/]. These efforts lack aformal execution mechanism for run-time interaction of the publicconversation process and the local business process.

One embodiment of the present invention can be characterized as a methodof coordinating choreographed exchange messages in an electroniccommerce conversation between a first party and a second party. Aninternal workflow process is associated with the second party. Themethod includes the second party receiving a message. The message isintended to be part of a conversation conforming to an electroniccommerce conversation process standard. The standard may be a publicstandard such as one of the standards identified above, or it may be aprivate standard. In addition, the conversation may conform to a privateagreement between the parties. This agreement may be reachedbilaterally, by participation in a group, or by any other mechanism. Themessage received is verified, preferably against the conversationprocess standard and against the history of the conversation, forinstance, a history maintained as a conversation instance. In addition,when a private agreement exists between the parties, the message may beverified against the private agreement. Message exchanges that are partof a particular conversation instance may be coordinated by assignmentof a collaboration ID. Processing of the message includes reporting themessage, either the text of the message, a portion of the message orinformation responsive to the message, to a task activation datastructure. This data structure is accessible to the conversation managerand is used by a workflow processor to satisfy one or more activationconditions. The activation conditions are compared asynchronously tocontents of the data structure. A component associated with the workflowprocessor, such as a task or an action or the workflow processor itself,generates a workflow message which is received and used to prepare aresponse to the message. At one or more times following receipt of themessage, the history of the conversation is updated.

Another embodiment of the present invention is a method of coordinatingan electronic commerce conversation between enterprises, a workflowwithin one of the enterprises and one or more actions that are part ofthe workflow. This method includes processing a plurality of messages ina conversation between enterprises that is intended to comply with anelectronic commerce conversation process standard. For at least one ofthe messages, the method includes posting information responsive to themessage, such as the message, a portion of the message or informationresponsive to the message, from a conversation management process to atask activation data structure. The internal workflow engine, actingasynchronously from the conversation, uses the task activation datastructure to activate one or more actions in the workflow when theposted information satisfies a task activation condition. In someinstances, one or more messages are generated and sent to theconversation process, corresponding to the activated action. In thismethod, prior to posting information responsive to the message, theconversation manager may verify that the message conforms to theconversation process standard, the history of the conversation, aprivate agreement between the parties, or combination of these factors.

Computer-based conversation systems parallel to the methods describedabove provide additional embodiments of the present invention. One suchembodiment includes at least one computer system, including resources toprocess logic. A task activation data structure is accessible throughthe computer system. Conversation manager logic is operable on computersystem. The conversation manager logic processes a conversation with thetrading partner, including messages, in conformance with an electroniccommerce conversation process standard. In some cases, the conversationalso may be in conformance with an agreement between trading partners.The conversation manager logic verifies that a particular messageconforms to a history of a particular conversation, to the conversationprocess standard, to a private agreement, or combination of thesefactors. The conversation manager logic generates at least one entry inthe task activation data structure corresponding to the particularmessage. This device further includes process manager logic operable oncomputer system and in communication with the conversation managerlogic. The process manager logic manages triggering of tasks in aninternal workflow. The internal workflow is not generally exposed to thetrading partner. The process manager logic further accesses the taskactivation data structure to determine whether any task activationconditions have been satisfied. The device yet further includes actionmanager logic, operable on the computer system and in communication withthe process manager logic, that dispatches and invokes actions in theinternal workflow. In some variations on this embodiment, more than oneof the logic components may be combined into a single program orroutine, or may run on a single computer system. In two variations onthis embodiment, message handling components may be shared among andutilized by different logic components or separate message handlingcomponents may function separately for the different logic components.

While the present invention is disclosed by reference to the preferredembodiments and examples detailed above, it is understood that theseexamples are intended in an illustrative rather than in a limitingsense. Computer-assisted processing is implicated in the describedembodiments. Accordingly, the present invention may be embodied inmethods for computer-assisted processing, systems including logic toimplement the methods, media impressed with logic to carry out themethods, data streams impressed with logic to carry out the methods, orcomputer-accessible processing services. It is contemplated thatmodifications and combinations will readily occur to those skilled inthe art, which modifications and combinations will be within the spiritof the invention and the scope of the following claims..

We claim as follows:
 1. A method of supporting an inter-enterprisebusiness interaction that includes electronic exchange of XML-basedmessages and activation of local processes internal to a businessentity, including: maintaining in memory a template model of aninter-enterprise business interaction that includes exchange ofXML-based messages, wherein the template model is a data object thatinternally represents an electronic commerce conversation processstandard compliant, XML-based specification of at least an order andtiming of electronic messages exchanged in the inter-enterprise businessinteraction; receiving an inbound message and verifying that the inboundmessage conforms to a conversation instance of the template model,including conforming to a history of conversation flow in theinter-enterprise business interaction, the history including the orderand timing of messages exchanged in the conversation instance;submitting at least part of the inbound message to an internal processmanager for posting to a task activation data structure that is used toactivate local processes asynchronously from the conversation flow;receiving, after at least one task activation, information responsive tothe inbound message; and preparing and sending an outbound message thatconforms to the conversation instance of the template model and thatincludes the information responsive to the inbound message.
 2. Themethod of claim 1, further including verifying that the inbound messageconforms to an inter-enterprise conversation agreement between at leasta first entity sending the inbound message and a second entity receivingthe inbound message.
 3. The method of claim 1, further includingupdating the history of the conversation instance to reflect sending ofthe outbound message.
 4. A non-transitory machine readable storage mediaimpressed with program instructions that, when executed by a processor,enable the processor to support an inter-enterprise business interactionthat includes electronic exchange of XML-based messages and activationlocal processes internal to a business entity, wherein the supportcomprises: maintaining in memory a template model of an inter-enterprisebusiness interaction that includes exchange of XML-based messages,wherein the template model is a data object that internally representsof an electronic commerce conversation process standard compliant,XML-based specification of at least an order and timing of electronicmessages exchanged in the inter-enterprise business interaction;receiving an inbound message and verifying that the inbound messageconforms to a conversation instance of the template model, includingconforming to a history of conversation flow in the inter-enterprisebusiness interaction, the history including the order and timing ofmessages exchanged in the conversation instance; submitting at leastpart of the inbound message to an internal process manager for postingto a task activation data structure that is used to activate localprocesses asynchronously from the conversation flow; receiving, after atleast one task activation, information responsive to the inboundmessage; and preparing and sending an outbound message that conforms tothe conversation instance of the template model and that includes theinformation responsive to the inbound message.
 5. The non-transitory,machine readable memory of claim 4, wherein the program instructions,when executed by the processor, cause the processor to support, furtherincluding verifying that the inbound message conforms to aninter-enterprise conversation agreement between at least a first entitysending the inbound message and a second entity receiving the inboundmessage.
 6. The non-transitory, machine readable memory of claim 4,wherein the program instructions, when executed by the processor, causethe processor to support, further including updating the history of theconversation instance to reflect sending of the outbound message.
 7. Amethod of asynchronously communicating internal task-generatedinformation between an inter-enterprise business interaction thatincludes electronic exchange of XML-based messages and local processesinternal to a business entity, including: maintaining in memory atemplate model of an inter-enterprise business interaction that includesexchange of XML-based messages, wherein the template model is a dataobject that internally represents of an electronic commerce conversationprocess standard compliant, XML-based specification of at least an orderand timing of electronic messages exchanged in the inter-enterprisebusiness interaction; receiving via a task activation data structure atleast part of an inbound message that has been subject to verificationof conformance to a conversation instance of a template model, wherein:the template model is a data object that internally represents of anelectronic commerce conversation process standard compliant, XML-basedspecification of at least an order and timing of electronic messagesexchanged in the inter-enterprise business interaction; and theverification of conformance to the instance of the template modelincludes conformance to a history of conversation flow in theinter-enterprise business interaction, the history including the orderand timing of messages exchanged in the conversation instance;evaluating, asynchronously from exchange of messages in theinter-enterprise business interaction, the part of the inbound messagereceived via the task activation data structure, as satisfying a taskactivation condition and activating a task responsive to the taskactivation condition; and sending information generated by the taskactivated that is responsive to the inbound message.
 8. The method ofclaim 8, wherein the verification further includes verification that theinbound message conforms to an inter-enterprise conversation agreementbetween at least the first entity sending the inbound message and thesecond entity receiving the inbound message.
 9. A non-transitory machinereadable storage media impressed with program instructions that, whenexecuted by a processor, enable the processor to asynchronouslycommunicate internal task-generated information between aninter-enterprise business interaction that includes electronic exchangeof XML-based messages and local processes internal to a business entity,wherein the asynchronous communication comprises: maintaining in memorya template model of an inter-enterprise business interaction thatincludes exchange of XML-based messages, wherein the template model is adata object that internally represents of an electronic commerceconversation process standard compliant, XML-based specification of atleast an order and timing of electronic messages exchanged in theinter-enterprise business interaction; receiving via a task activationdata structure at least part of an inbound message that has been subjectto verification of conformance to a conversation instance of a templatemodel, wherein: the template model is a data object that internallyrepresents of an electronic commerce conversation process standardcompliant, XML-based specification of at least an order and timing ofelectronic messages exchanged in the inter-enterprise businessinteraction; and the verification of conformance to the instance of thetemplate model includes conformance to a history of conversation flow inthe inter-enterprise business interaction, the history including theorder and timing of messages exchanged in the conversation instance;evaluating, asynchronously from exchange of messages in theinter-enterprise business interaction, the part of the inbound messagereceived via the task activation data structure, as satisfying a taskactivation condition and activating a task responsive to the taskactivation condition; and sending information generated by the taskactivated that is responsive to the inbound message.
 10. Thenon-transitory, machine readable memory of claim 8, wherein theverification of conformance further includes verification that theinbound message conforms to an inter-enterprise conversation agreementbetween at least the first entity sending the inbound message and thesecond entity receiving the inbound message.